-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refind: account for btrfs setups when generating manual stanzas #48906
Conversation
@sgn @ahesford May I ask you to please take a look at this commit. I already set my git commit email to a non-no-reply one. I would probably have to git-rebase or something. As for the errors in compiling for aarch64, I have no idea why this package didn't compile successfully this time around as I had made no changes to the compilation phase but only to the post-install kernel hook. Thank you in advance :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know much about rEFInd and know pretty much nothing about btrfs, but all of the magic in the hook should be dorpped in favor of simply exposing two additional variables in /etc/default/refind-kernel-hook.conf
. Something like REFIND_MENU_LABEL
can provide the text for the volume
line and default to Void Linux
, while something like REFIND_BOOT_PREFIX
(or maybe some better name that I can't think of at the moment) can default to empty and be used in place of your ${rootfssubvol}${efiprefix}
paths in the loader
and initrd
lines.
ac296e2 /etc/default/refind-kernel-hook.conf
After running |
@sgn maintainer ping Although initially my PR focused on btrfs setups, the simple changes proposed by @ahesford in both /etc/default/refind-kernel-hook.conf and /etc/kernel.d/post-install/50-refind are more universal as they can save a lot of trouble when installing Void manually (either through chroot from a different distribution or xchroot from Void). My argument is that these ways of installation are officially documented in Void Linux Docs (so refind could include the appropriate changes). On top of that, the part where P.S. the first workflow run failed for aarch64 (both glibc and musl) but I ran a cross-compilation of aarch64-glibc on the upstream tree yesterday and it succeeded this time so the compilation errors must've had to do with some dependency incompatibilities at the time or something. That's my guess. What do y'all think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems fine to me. Please squash the commits.
0797306
to
11c917a
Compare
As rEFInd won't cross-compile for aarch64 (both glibc and musl), I created this bug report #49170 |
Why do you remove the patch? |
@sgn When you take a look at the entire thing - https://github.com/void-linux/void-packages/pull/48906/files, you'll see that the patch is not removed but it comes with your new patch. Also the name is changed from add-cross-compile-support.patch to add-cross-compile-support-and-fix-binutils-aarch64.patch to reflect the added changes. If you want me to squash any of the three commits, please let me know. |
@ahesford @sgn is this PR mergable? If I were to argue for the merge, I'd say that not only does it introduce sgn's patch that fixes aarch64 build, but it also makes necessary changes in the post-install kernel hook. So far, the hook has only been able to generate entries that work with EFI mounted in /boot. I'm really surprised no one ever raised this issue before.
Given what I said before, I would even argue that the defaults could be Looking forward to hearing from you guys :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please make some minor adjustments and squash these commits down to one.
I don't think you should rename the patch; its original name is sufficiently descriptive, and changing the name makes tracking changes a little more confusing. |
OK, done. Is it OK now? :) |
While REFIND_LABEL identifies the volume on which vmlinuz and initramfs files reside REFIND_BOOT_PREFIX prepends a path that is relative to this volume. This commit also fixes aarch64 build problems related to binutils 2.38+
Closes: void-linux#48906 [via git-merge-pr]
Testing the changes
Local build testing
I built this PR locally for my native architecture, x86_64-glibc as well as for aarch64-glibc [EDIT: Feb 26 09:34:52 PM CET 2024].
My setup
/etc/default/refind-kernel-hook.conf
/boot/efi/EFI/refind/refind.conf
scanfor internal works as it takes also_scan_dirs as a prefix to where to find vmlinuz and initramfs files.
However, manual stanzas generated by /etc/kernel.d/post-install/50-refind hook get me nowhere near bootable entries.
The patch that I came up with may not be perfect but it works on my installation.
Further testing is needed, especially for people with EFI mounted at /boot and using filesystems other than btrfs.
To test the changes one needs to run xbps-reconfigure -f linux6.6 or whichever kernel one's running (also make sure to adjust the settings in /etc/default/refind-kernel-hook.conf)